调试高 CPU 使用率 您所在的位置:网站首页 linux 限制cpu使用率 调试高 CPU 使用率

调试高 CPU 使用率

2023-08-19 22:42| 来源: 网络整理| 查看: 265

调试 .NET Core 中的高 CPU 使用率 项目 05/10/2023

本文适用于: ✔️ .NET Core 3.1 SDK 及更高版本

本教程将介绍如何调试 CPU 使用率过高的情况。 使用提供的示例 ASP.NET Core Web 应用 源代码存储库,可以故意造成死锁。 终结点将停止响应并遇到线程累积问题。 你将了解如何使用各种工具,通过几条关键的诊断数据诊断此情况。

在本教程中,你将:

调查 CPU 使用率是否过高 使用 dotnet-counters 确定 CPU 使用率 使用 dotnet-trace 进行跟踪生成 PerfView 中的配置文件性能 诊断并解决 CPU 使用率过高的问题 先决条件

本教程使用:

.NET Core 3.1 SDK 或更高版本。 示例调试目标以触发场景。 dotnet-trace 以列出进程并生成配置文件。 dotnet-counters 以监视 CPU 使用率。 CPU 计数器

在尝试收集诊断数据之前,需要观察 CPU 状况是否过高。 使用以下命令从项目根目录运行示例应用程序。

dotnet run

若要查找该进程 ID,请使用以下命令:

dotnet-trace ps

注意命令输出中的进程 ID。 我们的进程 ID 是 22884,你的进程 ID 将不同。 若要检查当前的 CPU 使用率,请使用 dotnet counters 工具命令:

dotnet-counters monitor --refresh-interval 1 -p 22884

refresh-interval 是计数器轮询 CPU 值间隔的秒数。 输出应与以下内容类似:

Press p to pause, r to resume, q to quit. Status: Running [System.Runtime] % Time in GC since last GC (%) 0 Allocation Rate / 1 sec (B) 0 CPU Usage (%) 0 Exception Count / 1 sec 0 GC Heap Size (MB) 4 Gen 0 GC Count / 60 sec 0 Gen 0 Size (B) 0 Gen 1 GC Count / 60 sec 0 Gen 1 Size (B) 0 Gen 2 GC Count / 60 sec 0 Gen 2 Size (B) 0 LOH Size (B) 0 Monitor Lock Contention Count / 1 sec 0 Number of Active Timers 1 Number of Assemblies Loaded 140 ThreadPool Completed Work Item Count / 1 sec 3 ThreadPool Queue Length 0 ThreadPool Thread Count 7 Working Set (MB) 63

在 Web 应用运行的情况下,CPU 根本不会在启动后就立即被消耗,且会在 0% 进行报告。 使用 60000 作为路由参数导航到 api/diagscenario/highcpu 路由:

https://localhost:5001/api/diagscenario/highcpu/60000

现在,重新运行 dotnet-counters 命令。 如果只对监视 cpu-usage 计数器感兴趣,请将“--counters System.Runtime[cpu-usage]”添加到上一命令中。 我们不确定是否正在消耗 CPU,因此将监视与上面相同的计数器列表,以验证计数器值是否在应用程序的预期范围内。

dotnet-counters monitor -p 22884 --refresh-interval 1

你应会看到 CPU 使用率增加,如下所示(具体取决于主机,预期 CPU 使用率会有所不同):

Press p to pause, r to resume, q to quit. Status: Running [System.Runtime] % Time in GC since last GC (%) 0 Allocation Rate / 1 sec (B) 0 CPU Usage (%) 25 Exception Count / 1 sec 0 GC Heap Size (MB) 4 Gen 0 GC Count / 60 sec 0 Gen 0 Size (B) 0 Gen 1 GC Count / 60 sec 0 Gen 1 Size (B) 0 Gen 2 GC Count / 60 sec 0 Gen 2 Size (B) 0 LOH Size (B) 0 Monitor Lock Contention Count / 1 sec 0 Number of Active Timers 1 Number of Assemblies Loaded 140 ThreadPool Completed Work Item Count / 1 sec 3 ThreadPool Queue Length 0 ThreadPool Thread Count 7 Working Set (MB) 63

在整个请求期间,CPU 使用率将在增加的百分比附近徘徊。

提示

若要可视化更高的 CPU 使用率,可以在多个浏览器选项卡中同时使用此终结点。

此时,你可以放心地说 CPU 运行的速度比预期的要高。 确定问题的影响是找出原因的关键。 除了使用诊断工具,我们还会通过 CPU 使用率较高的影响来找出问题的原因。

使用探查器分析高 CPU 使用率

当分析具有高 CPU 使用率的应用时,需要一个诊断工具来提供代码正在执行的操作的见解。 常见的选择是探查器,并且有不同的探查器选项可供选择。 dotnet-trace 可以在所有操作系统上使用,但是,与 Linux 或适用于 Windows 的 ETW 的“perf”等内核感知探查器相比,其安全点偏差和仅限托管的调用堆栈的限制产生的信息更加笼统。 如果性能调查仅涉及托管代码,通常 dotnet-trace 就足够了。

Linux Windows

perf 工具可用于生成 .NET Core 应用配置文件。 我们将演示此工具,尽管也可以使用 dotnet-trace。 退出示例调试目标的上一个实例。

设置 DOTNET_PerfMapEnabled 环境变量,使 .NET 应用在 /tmp 目录中创建 map 文件。 perf 使用此 map 文件按名称将 CPU 地址映射到 JIT 生成的函数。 有关详细信息,请参阅导出 perf 映射。

注意

.NET 6 为用于配置 .NET 运行时行为的环境变量标准化前缀 DOTNET_ 而不是 COMPlus_。 但是,COMPlus_ 前缀仍将继续正常工作。 如果使用的是早期版本的 .NET 运行时,则环境变量仍应该使用 COMPlus_ 前缀。

在同一终端会话中运行示例调试目标。

export DOTNET_PerfMapEnabled=1 dotnet run

再次使用高 CPU API (https://localhost:5001/api/diagscenario/highcpu/60000) 终结点。 当它在 1 分钟请求内运行时,对进程 ID 运行 perf 命令:

sudo perf record -p 2266 -g

perf 命令将启动性能收集过程。 让它运行大约 20-30 秒,然后按 Ctrl+C 退出收集过程。 可以使用相同的 perf 命令来查看跟踪的输出。

sudo perf report -f

还可以使用以下命令生成 flame-graph:

git clone --depth=1 https://github.com/BrendanGregg/FlameGraph sudo perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > flamegraph.svg

此命令生成 flamegraph.svg,你可以在浏览器中查看 flamegraph.svg 以调查性能问题:

在 Windows 上,可以使用 dotnet-trace 工具作为探查器。 使用之前的示例调试目标,再次使用高 CPU (https://localhost:5001/api/diagscenario/highcpu/60000) 终结点。 当它在 1 分钟请求内运行时,使用 collect 命令,并包含 providers 选项来指定所需的提供程序:Microsoft-DotNetCore-SampleProfiler,以便收集应用的跟踪,如下所示:

dotnet-trace collect -p 22884 --providers Microsoft-DotNETCore-SampleProfiler

让 dotnet-trace 运行大约 20-30 秒,然后按 Enter 退出收集。 结果是位于同一文件夹中的 nettrace 文件。 nettrace 文件是在 Windows 上使用现有分析工具的好方法。

使用 PerfView 打开 nettrace:导航到 samples/core/diagnostics/DiagnosticScenarios/,单击 nettrace 文件旁边的箭头。 打开“线程时间(使用 StartStop 活动)堆栈”,然后选择顶部附近的“CallTree”选项卡。 选中其中一个线程左侧的框后,文件应该与下图类似。

使用 Visual Studio 分析高 CPU 数据

可以在 Visual Studio 中分析所有 *.nettrace 文件。 若要在 Visual Studio 中分析 Linux *.nettrace 文件,除了其他必要的文档外,还要将 *.nettrace 文件传输到 Windows 计算机,然后在 Visual Studio 中打开 *.nettrace 文件。 有关详细信息,请参阅分析 CPU 使用量数据。

请参阅 用于列出进程的 dotnet-trace 用于检查托管内存使用情况的 dotnet-counters 用于收集和分析转储文件的 dotnet-dump dotnet/diagnostics 后续步骤

调试 .NET Core 中的死锁



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有